如果連「答應了什麼、怎樣算完成」都不知道，我們到底在敏捷什麼？

一個很敏捷的專案現場

先講一個故事。案例經過去識別化與合併改寫，你可以把它想成很多專案的平均值。

某個系統整合案，團隊自我介紹時說：「我們跑敏捷。」

證據看起來很充分：有 Sprint，兩週一輪；有每日 Standup；有看板（Kanban），上面貼滿 Ticket；需求用一句話開單，例如「幫我加一個報表匯出」；沒有厚重的規格書，因為「文件是瀑布時代的東西」。

專案中期，客戶窗口在一次會議上問了兩個問題：

「所以這一版交付的時候，我會拿到哪些功能？」

「你們怎麼判斷這些功能算是做完了？」

會議室安靜了幾秒。PM 翻了翻看板，上面有四十幾張 Ticket，有些叫「調整 API」，有些叫「修正畫面」。沒有人能從看板上回答這兩個問題。

最後，所有人的視線移向坐在角落的資深工程師。他想了一下，把這一版會有什麼、哪些跟客戶上次口頭提過的事情有關、哪些其實還沒對齊，講得清清楚楚。

會議繼續，危機解除。團隊走出會議室，結論是：

「還好有他在。」

而不是：

「為什麼這兩個問題，需要靠某個人的記憶才能回答？」

當時團隊怎麼理解這件事

當時團隊的自我認知大概是這樣：

我們是敏捷團隊，需求本來就會變，所以不用先寫清楚；規格書、驗收條件那些是瀑布的東西，寫了也是浪費；反正每兩週都有 Demo，客戶有意見再改就好。

這套說法最迷人的地方在於：每一句單獨看都有幾分道理，合在一起卻剛好把工程上最重要的兩個問題繞開了：

我們到底答應了什麼？

怎樣算完成？

這不是敏捷與瀑布之爭。這兩個問題，瀑布要回答，敏捷也要回答，只是回答的形式與時機不同。而這個團隊的實際狀態是：兩邊都沒有回答。

缺席的不是文件，是責任

把「文件太重」當成不留任何紀錄的理由，是這個系列要處理的第一個混淆。

那場會議上真正缺席的東西，攤開來看至少有：

沒有人知道這一版的 Scope
→ 缺的是 Requirement 的基準，不是「一份很厚的規格書」

沒有人講得出怎樣算完成
→ 缺的是 Acceptance Criteria，不是「驗收文件的格式」

客戶上次說過什麼、改過什麼，只存在某些人的記憶
→ 缺的是 Change 的紀錄，不是「變更管理委員會」

注意一件事：這些缺口，最後都有被補起來——被那位資深工程師用記憶、經驗與人際關係補起來。

專案繼續往前走，於是團隊得到一個錯誤結論：

「你看，不寫那些東西也沒出事。」

其實是：

流程沒有解決問題，是有人代替流程解決了問題。

這個現象，是整個系列的主角之一。後面我們會給它一個正式一點的分析（Hero Culture、Tacit Knowledge、Bus Factor 這些詞都會出場），在那之前，先用一個比較傳神的暫稱：

血脈壓制，或者叫大神壓制。

「連瀑布都沒做好」是什麼意思

標題不是在說「你應該改回瀑布」。

瀑布（Waterfall／Predictive）與敏捷（Agile／Adaptive）是兩套不同的做法，但它們有共同的底線：都要求你知道自己承諾了什麼、都要求「完成」有明確的判準、都要求變更是被看見的，而不是被默默吸收的。

瀑布用它的方式回答：先建立需求基準，再管理變更，驗收有明確的依據。敏捷用另一種方式回答：把承諾切小、把回饋週期縮短，讓答案逐步浮現。至於這兩種回答各自的邏輯與代價，是 Day 02 與 Day 03 的主題，這裡先不展開。

重點是：兩邊都沒有一條規則叫做「不用知道自己答應了什麼」。

所以「連瀑布都沒做好」的意思是：很多自稱敏捷的團隊，並不是從瀑布「升級」到敏捷，而是把瀑布的承諾與驗收丟掉了，也沒有換上敏捷的排序與回饋，只剩下 Sprint、Standup、看板這些外觀，中間的洞全部靠少數高手補。

這種狀態有個常見的名字：假敏捷。它的成本不會消失，只是換了一個地方記帳。

這次到底誰在吸收代價？

這個系列每一篇都會做一次同樣的檢查。理論上，專案遇到不確定性時，可以在這些變數之間做取捨：

Scope       □
Time        □
Cost        □
Quality     □
Risk        □
人          □

回頭看開場的故事：Scope 沒有少、時程沒有延、也沒有加人加預算、Demo 照開。那麼「客戶問到底要交什麼」這個不確定性，是誰吸收掉的？

是那位資深工程師。用他的記憶、他的加班、他在會議室裡即席重建整個承諾的能力。

這一格，系列前半段會一直被勾到你麻痺為止：

Scope       □
Time        □
Cost        □
Quality     □
Risk        □
人          ■   ← 又是這格

當 Scope、Time、Cost、Quality 全都不肯交換時，最後被拿來交換的通常就是人。

這 30 天要做什麼

這個系列不是「瀑布 vs. 敏捷誰比較好」的比較文，也不是 Scrum 教學。真正想回答的問題是：

當需求不確定、時間有限、利害關係人意見會變，一個團隊到底靠什麼把事情做對？

整個系列分四幕：

第一幕｜Day 01–07
我們到底在承諾什麼？
（瀑布與敏捷各自在賣什麼、Constraint 與 Trade-off、Stakeholder 與談判）
          ↓
第二幕｜Day 08–14
大神在，所以我們一直以為沒問題
（需求、介面、驗收、決策、變更，是怎麼被一個人的腦袋撐起來的）
          ↓
第三幕｜Day 15–21
大神不在，小專案開始翻車
（用一個去識別化的小型系統整合案例，看假敏捷怎麼一步步爆炸）
          ↓
第四幕｜Day 22–30
同一個專案，重新用敏捷做一次
（沒有大神，也能把事情做完的最小工程配備）

每一篇會維持三個固定元素：檢查「這次到底誰在吸收代價」；追問「大神腦袋裡藏了什麼」——每次靠經驗救回來的事件，真正缺的是哪個工程責任；最後留下一個小型 Artifact，30 天累積成一套輕量的工程工具箱。

案例全部經過去識別化與合併改寫，聚焦「流程為什麼失效」，而不是「誰搞砸了」。

今日 Artifact｜假敏捷自我檢查表

Day 1 先留下一份最小的自我檢查表。不用改流程、不用開會，自己誠實勾選就好：

□ 我講得出「這一輪結束時，我們承諾交付什麼」
□ 我講得出「其中任何一項，怎樣算完成」
□ 需求改了的時候，有留下紀錄，而不是只存在某人腦中
□ 客戶問「會拿到什麼」時，答案來自看板或文件，不是來自某個人
□ 最資深的那個人下週請假，上面四題的答案不變

五題全勾，恭喜你，這個系列你可以當複習看。

只要有一題是「要問一下那個資深的」，那麼接下來 29 天，我們談的就是你的專案。

今日一句

不是每一次成功都證明流程有效；有時候只是有人剛好把流程缺的東西全做了。

明天先從被誤解最深的那一邊開始：瀑布到底在賣什麼？提示：答案不是甘特圖。